Just as with almost every software sector, software licensing has fundamentally evolved during the last decades. What used to be a necessary non-functional component that engineering departments had to implement or integrate at some point, is now commonly accepted as an indispensable cross-departmental tool.


Early licensing mechanisms were obviously born in an era with limited or no connectivity and a less diverse programming language and device landscape. Limited connectivity meant that licensing mechanisms had to be implemented exclusively on the client side. Regardless if an in-house or a professional solution was in place. Without a connected central component, licensing mechanisms had to locally solve several problems.

Let us list the most commonly used mechanisms.


This mechanism assumes that a license file containing the license parameters exists in an installation’s directory. Upon each program start, this license file is read in order to enforce its parameters. Obviously, when using such mechanisms, it has to be ensured that:

  • valid license files can only be created by the vendor
  • valid license files cannot be copied

In this context, digital signing the license file is fundamental.


This mechanism assumes that the client installation can translate a license key (typically in form of a GUID) into license parameters. Usually, this is achieved through some kind of hashing. Due to its simplicity, this used to be arguably the most widespread licensing mechanism. The major challenge of this approach is to ensure that a license key cannot be used multiple times.


Protection dongles have been traditionally used in rather expensive software applications. Internally, such dongles might include license files or license keys. Due to the obvious practical  limitations, dongles have never achieved significant customer popularity.


Traditional licensing mechanisms share some common limitations:

  • Every license parameter change results in a new license distribution (new file/key/dongle etc.), bothering both vendors and licensees.
  • Licensing is deeply embedded into the application, so that product managers are not able to define or adapt licensing models (e.g., named vs user, or floating) without having to involve the engineers.


The huge advancements of the past decade in cloud and network technologies have paved the way for more sophisticated licensing as service solutions, letting engineers focus on their application’s core and allowing product managers easily experiment and implement all software licensing models such as subscriptions, pay per use, floating, trials or perpetual.

Just as all modern “as a Service” solutions, LaaS is typically delivered through a modern and secure web API. The software vendor does not need to install anything on-premise. However, the API has to be obviously integrated into the “to be licensed” application. If you are migrating from an existing licensing mechanism, additional points have to be considered.


LaaS solutions can address all platforms, operating systems and programming languages, since contrary to legacy systems, they do not provide any client libraries. Https connectivity is the only requirement. The vendor does have an initial integration effort. However, in most cases, engineers never have to deal with licensing again, since application core and licensing become decoupled.


The obvious advantage of having a license server is the tracking of activations. This results in a more robust protection, since it is much easier to track and prevent suspicious or non-compliant activity.


Similar to SaaS solutions, the pricing of LaaS is either fixed or pay as you grow. The number of active licenses is the most commonly used metric determining the price.


LaaS give software vendors the flexibility to offer all kinds of software licensing models such as named and floating, subscriptions, pay per use, trials or perpetual. While some of these models were feasible with traditional approaches, floating and pay-per-use models are significantly easier in LaaS, especially for standalone desktop applications.


Since LaaS connects installations with a central server component, LaaS providers quickly discovered that it is possible to extend their solutions with out of the box analytics: installation analytics, compliance analytics or even going beyond licensing usage or feature analytics. While usage or feature analytics can be implemented with other tracking technologies, primarily coming from the web domain e.g., Google Analytics, the coupling with licensing offers vendors the ability to analyze the behavior of their users at the lowest identifiable granularity level.


All aforementioned points constitute LaaS a truly cross-departmental tool, helping product managers, engineers, sales executives and support engineers  in their respective fields. Therefore, it is imperative to involve all these departments when evaluating a LaaS solution.