Floating licensing or concurrent licensing is a software licensing model in which an amount of licenses are shared among a larger number of authorized users or installations. Contrary to the named software licensing model, in which a named user or installation has guaranteed access to the software application, floating relies on a central license server which restricts the number of users simultaneously accessing the application. If all licenses are in use, a new user trying to access the application has to wait until somebody else disconnects.




Naturally, floating licensing offers customers a lot more flexibility. Although a floating license is typically more expensive than a named one, this model has always been very popular among customers. However, in recent years, software vendors have been consistently trying to move away from floating, and enforce named licensing, since named usually benefits the vendor rather than the customer. At the end of the day, it depends on the floating price factor e.g., a floating license can be typically priced between 3 and 5 times as much as a named. This factor might obviously vary depending on the application.

While some vendors offer either floating or named licensing (per customer), modern software licensing-as-a-service solutions enable mixing them, which means that a customer can buy  named licenses in order to provide guaranteed access to power users and  floating licenses for non-power users, taking advantage of both models.




A central software component (let us call this the license server) is obviously necessary in order to enforce floating license compliance. Thus, when the client application starts, it communicates with the license server in order to receive a valid token. Ideally, the session period is not hard-coded but a license parameter.




In a perfect world, clients send a session close (disconnect) event when access to the software application is not necessary anymore. This is mandatory in order to make sure that floating tokens become available again, ready to be assigned to other clients. However, especially in web applications in which users frequently close the browser without explicitly logging off, such session close events are not sent, resulting in zombie sessions. In order to circumvent this, the session period defines the maximum inactivity period in minutes for a client.


Standalone desktop applications (without user management and sign-in process) lack a central component (application server) that implements floating functionality. Therefore, such applications have to rely on an external software licensing API acting as a license server.


SaaS and web apps are better equipped to implement floating licensing mechanisms, since they already have some kind of login and session management mechanism. However, even such applications should consider the advantages of a modern licensing API, before implementing an in-house solution.


It is particularly interesting to monitor the actual floating token usage, in order to identify if more (or even less) tokens are required, both for vendors and customers. In this context, each time a client is unable to access the software application because all floating tokens are assigned, this should be logged and visualized in a meaningful way.

You can read more about SLASCONE’s floating license approach here.