SLM license types

The license deals vary, but the license types remain the same. Therefore, the SLM does not license according to a license deal, but according to the various license types.

Infor applications can be licensed in various ways. To see how your application must be licensed, see the Software License Agreement (SLA). Depending on the Infor pricing strategy, a restricted set of license types can be assigned to a specific application. For example, some applications can be licensed through any license type, and others can only be licensed through a server license.

In general, the license types are distinguished in node locking and user locking. With a node-locking license, the adopting application can only work on a specific node in your network. A network node can be a server but also a desktop or a particular instance of an application. With a user-locking license, the adopting application can only work with specific named users or with a limited amount of concurrent users.

SLM supports these license types:

After a license request is made, the license configuration (License file) is checked by SLM on how many users, servers, or instances can use the application. Then, according to the license type, the specific named user, server, or instance is verified.

Some adopting application can be licensed with all the various license types, and others can handle only a selection of licenses.

Concurrent user license

With the concurrent user license, the SLM server is not interested in the specific name of a user. The SLM server only counts the number of concurrent users at a particular time. The number of users for which the Activation Key is valid is specified in the SLA. If this number exceeds the amount of concurrent users the SLM server rejects the license request from the adopting application.

Named User license

If an adopting application uses Named User licensing, the SLA states the number of named users that can use that application. The SLM server keeps track of a list of all specific users that are permitted to use that application. The server rejects a license request from an adopting application if the SLM server does not know the specific user name.

To work with some role-based licensing mechanism, the named user licenses are distinguished into light and heavy users. The adopting application can specify some rights to a specific role.

Infor only validates the amount of named users. Infor does not know the specific names of these users.

Some applications automatically synchronize the user names of their authorization module with the SLM server.

The SLM server keeps track of the usage. It logs the number of logins in the application of the specific named user. The license requests from multiple desktops are not blocked by SLM, but they are logged in the usage log files for reference or auditing purposes.

Server license

If an adopting application uses Server licensing, the SLA states the number of servers that can run that application. The SLM server keeps track of a list of servers that can be used for an application.

Note 1: For some applications, manually configuring the servers on which the product can run is unnecessary. Through the SLM API, the application itself can upload the server IDs to the SLM server.

Note 2: For the license validation, Infor only registers the amount of named servers. Infor does not know the specific names of these servers.

Instance license

If an Infor application uses Instance licensing, the SLSA states the number of instances to be run with that application according to the contract. The SLM server keeps track of a list of instances that can use be used in the context of the application.

Note 1: For the license validation, Infor only registers the amount of instances per instance licensed product. Infor does not know the specific instances names.

Note 2: With SLM 2.5 and 7.x both instance and server licenses are kept under the server licenses in the license data.

Desktop license

Not in use

Confirmation and releasing of licenses

If an application claims a license, the application must frequently confirm this claimed license within a specified time interval, which is called the confirm time. If the confirm time has passed, the SLM server releases the license, assuming that the adopting application no longer runs correctly. If the application can provide a confirmation afterwards, the SLM server first tries to reestablish the license that was released previously. If unsuccessful, the server tries to provide a new license.

With this confirmation mechanism, requested licenses are always released within a specified time. Even if the adopting application has crashed or can no longer be reached.