Software License Management: what you should know

Ensure you run your software without overpaying on license fees, and stay legal.
9 August 2022

Saving on software license costs? Source: Shutterstock

Every piece of software, whether it’s installed on a phone, a laptop, a server, or used in the cloud, has a license. Even so-called “free” software (software that is freely distributable and amendable) comes with a license. The license lays out the terms and conditions under which the software can be used, and explains who can use the software, for how long, what levels of access users get to the code, and so on. Licenses are displayed when a user starts an application for the first time (in the form of a EULA – end-user license agreement) or accompanies the application as part of its distribution medium, like in the downloaded archive file.

Why is software license management important?

Managing software licenses ensures that organizations stay compliant with the terms of the license and, therefore, out of legal hot water. Additionally, if there’s a cost to owning the license to use a piece of software, managing the ratio between users and installations means that companies do not overspend on software, nor run software illegally.

In cloud services’ case, managing licenses to use a remote application or service will help ensure that the organization is getting maximum value from its monthly fees and that overuse of the cloud service won’t present an unpleasant bill at the month’s end.

What is software license management?

Software license management platforms typically comprise different elements, including but not limited to auditing, compliance checking, and submission of reports either to decision-makers, or in some cases, to statutory bodies.

Software license management platforms can also be a central source of information that lays out the differences between the various software licensing models. These are particularly numerous  in open-source software and cloud services.

For example, some cloud services charge on the basis of data throughput, bandwidth to an application, processor loads, or (more commonly) the number of end-users accessing the service.

In open-source software (more on this subject below), some licenses allow free use of any element of the supplied code without recourse to the developers, while others are more restrictive, requiring publication of any differences made to code, for example.

What’s meant by a software license

It’s simple enough to conceptualize what a piece of software is for most people: an app on a phone, a desktop icon that’s double-clicked, or a web-based service that you log into to get a day’s work done.

However, the detailed picture is much more complex. On an Android phone, for example, the operating system (Android) is licensed, as is the virtualized Java machine inside the OS. Additionally, every app will, in all likelihood, comprise different elements (often called libraries or frameworks, for example), each of which come with its own licenses.

And while tracking every single element down to the smallest detail is rarely necessary, organizations should be aware that, for example, macOS comes as a licensed piece of software, as do the various versions of Windows that run on company desktops. Servers hosted in-house or on virtual private servers in the cloud, too, will be licensed under the various terms with which Linux-based software often comes.

At scale, therefore, software license management platforms will clearly show their value, being capable of deep investigations right across an organization’s networks to ascertain what is running where, using – and based on – what.

What’s involved in managing software licenses

There are three basic elements of managing software licenses. The first is the discovery of assets right across the extended network. In today’s organizations, that network extends out from the LAN to the cloud and includes BYOD devices that appear on the LAN, assuming that those devices brought into the business are used in some way for the purposes of work.

IIoT and IoT devices should also be audited. In fact, anything connected to the corporate network needs to be cataloged. Cataloging should include both OS and application layers (if they are separate) and any extensions or add-ons to apps and services deployed anywhere in the company.

There are specialist software platforms available that will catalog specific devices like OT and IIoT devices (see other pages on this site), although the latest generation of software license management platforms should include such devices as part of their scanning.

The second part of the software license management suite will compare installed instances of software and hardware with purchased licenses and ensure that the terms of any licenses (even the so-called “free” versions) are not being breached.

The third element is the continuation of these processes as the organization’s operations continue. When new cloud services are spun up or subscribed to, these should join the software license catalog. Similarly, as staff leave or join the organization or hardware devices are retired or procured, license details will need to be added or scratched from the ongoing register. Continued compliance is essential, despite the many turns that today’s businesses will take as they deploy, use, and change their overall IT stack.

What about software licensing of open-source?

Developers creating new applications and services will invariably make use of pre-existing pieces of software, integrating these as libraries, frameworks or code layers into new and existing projects.

However, organizations should be aware that many such code elements are released under specific licenses which limit how they can be used, or have stipulations built-in that dictate how resulting products should be released.

This has two effects on companies running DevOps functions. Firstly, the process of software audit has to be granular and continuous to highlight which elements, such as libraries, are being integrated into a project. Use of these elements can pose a security issue in due course (many product owners were unaware that their platforms contained the Log4J code, for example), or have implications as to whether a piece of finished software can be released as a proprietary, closed product.

Using code released under certain versions of the GPL (GNU Public License) comes with particular stipulations, for instance.

While these issues may seem esoteric to many (indeed, there is a bewildering array of different software licenses, particularly in open-source), the continued development of widely-available code requires that all users of open-source software adhere to the terms of licenses.