Mechanism for managing third-party software licenses

Abstract

In a method for managing third-party software licenses, a first license for a first software is generated by a first license server. The first license includes wrapped therein a second license for a second software retrieved from a second license server of a third-party vendor. Functionality of the first software depends on the second software. Using a packaging tool, a downloadable user-specific local license application package is created that contains the first license in an encrypted form. The local license application package is deployed on a user compute node which has the first software installed. The local license package, when installed on the user compute node, can decrypt the first license and create, on that compute node, a localized version of the first license containing the second license by obfuscating or encrypting the first license with a local key generated using a unique node identifier of the user compute node.

Description

202408066MECHANISM FOR MANAGING THIRD-PARTY SOFTWARE LICENSESTECHNICAL FIELD

[0001] The present disclosure is directed, in general, management of software licenses, and in particular to methods, systems and computer program products for managing third-party software licenses in partially connected compute environments.BACKGROUND

[0002] Many modern software development projects rely on third party software which often requires a license. As an example, there could be a software A from a developer which depends on a software package B from a third-party vendor. When the developer sells a license for software A to a user, it must also include with it a license for software B. Hence, the developer of software A buys a license for software B from the third-party vendor. This license must be protected in some way so that it cannot be extracted and used for other purposes than serving in software A.

[0003] This is particularly a problem if the software A is a platform or framework software. In case of a platform or framework software, other parties may develop software applications that utilize or are based on the framework or platform. Those software applications naturally have a deeper integration and therefore access to resources of the platform or framework. In the described scenario, it can often require opening software A at a compute node of the user so that a software C can make use of it. In doing so, the license for software B (typically a simple license file) may be exposed and can be potentially copied outside of software A and used for other purposes.

[0004] Presently, it is a common practice that third-party licenses are not protected and simply just “hidden”. For example, the software A installation would include a file with the license for software B. Alternatively, a license server might be used. However, such a license server typically requires a network connection. For example, if the software A is an operational technology (OT) software running on shopfloor level, this network connection is not always available.202408066SUMMARY

[0005] Aspects of this disclosure provide methods, systems, and computer program products that can address and overcome one or more of the above-described technical challenges. An objective of the disclosure is to provide a mechanism to obtain a software license from a third-party vendor and wrap it into a license of a software such that the third-party software license cannot be extracted and used for other purposes but said software. The proposed mechanism does not require that the system that hosts the software has continuous network access to check the validity of a license.

[0006] A first aspect of this disclosure provides a computer-implemented method for managing third-party software licenses. The method comprises generating a first license for a first software by a first license server. The first license including wrapped therein a second license for a second software retrieved from a second license server of a third-party vendor, wherein functionality of the first software depends on the second software. The method further comprises creating, via packaging tool, a downloadable user-specific local license application package that contains the first license in an encrypted form. The method further comprises deploying the local license application package on a user compute node that has the first software installed thereon. When installed on the user compute node, the local license application package is configured to decrypt the first license and create, on the user compute node, a localized version of the first license containing the second license by obfuscating or encrypting the first license with a local key generated using a unique node identifier associated with the user compute node.

[0007] Further aspects of this disclosure provide a system and a computer program product embodying the described method.

[0008] Additional technical features and benefits may be realized through the techniques of the present disclosure. Embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed subject matter. For a better understanding, refer to the detailed description and to the drawings.202408066BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The foregoing and other aspects of the present disclosure are best understood from the following detailed description when read in connection with the accompanying drawings. To easily identify the discussion of any element or act, the most significant digit or digits in a reference number refer to the figure number in which the element or act is first introduced.

[0010] FIG. 1 is a schematic block diagram illustrating the architecture of a system for implementing a mechanism for managing third-party software licenses according to one or more embodiments.

[0011] FIG. 2 is a schematic block diagram illustrating a mechanism for validating a third-party software license at a user compute node according to one or more embodiments.DETAILED DESCRIPTION

[0012] FIGS. 1 and 2, discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged device. The numerous innovative teachings of the present application will be described with reference to exemplary non-limiting embodiments.

[0013] License management can be a complex issue in case of a primary vendor deploying a software to a customer / user, which depends on another software from a third-party vendor. The primary vendor must not only protect the functionality of its own software with an electronic license, but also the third-party software license. In many cases, the primary vendor may obtain the software license from the third-party vendor and place it as-is in the software container (e.g., Docker) deployed to the customer / user. While it may be possible in theory to limit the degree of access that a user has inside the container, to protect the third-party software license, it is often required to allow the user to influence what is inside the container, and therefore “see” what is inside the container. An example of this situation is when the software from the primary vendor is a framework or platform software,202408066 which is primarily intended to be used by the user / customer for developing or running their software. In this situation, very limited protection is available for the third-party software license at the user compute node.

[0014] Often, it is a requirement for the primary vendor that the third-party vendor is not able to trace their customers / users. For this reason, the third-party software license may not be limited to a specific customer / user, but may only be limited to a major release version of the third-party software. This can make the third-party software license particularly vulnerable to be used for unintended purposes or sold (e.g., in a black market), which can have significant business and / or legal consequences for the primary vendor.

[0015] It is an objective of the present disclosure to provide a mechanism for managing third- party software licenses that can prevent such misuse or at least make it prohibitively expensive to do so. The described solution aims at reducing the value (benefit vis-a-vis cost) of hacking a customer / user system to gain access to the licenses used. The solution provides a mechanism to obtain a software license from a third-party vendor and wrap it into a license of a software of the primary vendor in an encrypted manner, such that the third-party software license cannot be extracted and used for other purposes other than in the software from the primary vendor. The mechanism ensures that licenses that can be “seen” by the user are generated locally at the user compute node and are node-specific. Thus, if a malicious user copies this localized license and tries using it on a different node, it will not be valid. Also, the generated localized licenses may be short-lived, which can make hacking less profitable, especially if the effort for hacking is high. Furthermore, the described mechanism does not require that the customer / user system that hosts the software has continuous network access to check validity of a license, making it particularly suitable for OT software running at a field level.

[0016] In the embodiments illustrated herein, the software from the primary vendor is a framework or platform software. “Framework software” refers to software that provides the structure and tools for building applications. For example, framework software may include tools, libraries and guidelines designed to help developers build applications more efficiently. “Platform software” refers to software that provides the environment for applications to run. This can include the operating system, as well as any middleware that provides services to applications.

[0017] Turning now to the drawings, FIG. 1 shows the architecture of a system 100 for202408066 implementing a mechanism for managing third-party software licenses according to one or more embodiments. The architecture 100 includes a number of functional blocks, such as applications, tools, storage, etc., each of which realizes a distinct component or module that performs a specific function. The various functional blocks may be implemented in a computing environment in various ways, for example, as hardware and programming. The programming may take the form of processorexecutable instructions, and the hardware may include memory / storage media and processors to execute the instructions.

[0018] Referring to FIG. 1, the primary vendor (e.g., Siemens®), herein represented as vendor A, may provide a first license server 104 hosted on a first computing environment, typically including a cloud service, represented as vendor A cloud 102. The license server 104 may be implemented as a software application configured to distribute and manage licenses for a software A from the vendor A to client computers, such as a user compute node 130. The software A may include a framework or platform software. The functionality of the software A may depend on a software B (e.g., including a library) provided by a third-party vendor B. Vendor B may provide a second license server 108 for managing the distribution of licenses for the software B. The license server 108 may be hosted on a second computing environment, typically also including a cloud service, represented as vendor B cloud 106.

[0019] Vendor A may be provided with access to the cloud service 106 of vendor B, whereby the first license server 104 can retrieve a license B (for software B) 110 via the second license server 108. This may be implemented in many ways, for example, by way of the first license server 104 calling a function (get license B) in an API of the second license server 108, or vice versa. Vendor A may, via the first license server 104, request a license B with a specified expiration date, i.e., the license B may have a limited lifespan (e.g., one year) and may be limited to a specific major release number of the software B — for example, a license B that works for software B version 7.x will not work for software B version 8.x. Vendor A can provide the license B to its customers, but must ensure that the customers cannot use this license outside of the software A. In many situations, the vendor A may require only a single license B as it may not want separate licenses for different customers, to protect the customers’ details (e.g., customer name, how they are using software B, etc.) from being exposed. The license B can thus be valuable, since it is reusable. Therefore, it is important for vendor A to ensure that customers cannot read or easily extract this license.202408066

[0020] The first license server 104 may generate a license A (for the software A) 112 by wrapping therein the license B retrieved from the second license server 108. Wrapping means that the original license B is encrypted, and the encrypted license B becomes part of the license A. For example, the license A may start with the encrypted license B followed by the license string for license A. A signature over the entire license A can ensure that it cannot be manipulated. The license A can now also contain information such as expiration date or other limitations of use which are independent of those of license B. This way the vendor A can specify limitations of use that are much more restrictive than those of license B.

[0021] By way of the wrapping, the license A may contain the license B in an encrypted way so that it cannot be read or extracted by a customer / user. Consistent with the disclosed embodiments, the license A may also not be limited to a specific customer or user. That is, there may be only one license A at a given time which can be used by all customers of the vendor A. The license A may also have a specified expiration date, for example, at the same time or one year after the expiration date of the license B.

[0022] The first license server 104 may be configured to read / write licenses to a cloud storage 114 provided by the vendor A cloud service. After generating the license A, the first license server 104 may store the license A, containing license B in an encrypted form, in the cloud storage 114.

[0023] A packaging tool 116 may request the stored license A via the first license server 104 and create a local license application package 118 that is available for download to a customer / user. The local license application package 118 may comprise a bundle that includes necessary components (e.g., binary executable files, libraries, configuration files, dependencies, documentations / manuals, etc.) to install, run and manage a local license application 204 (see FIG. 2) on a user compute node 130. The local license application package 118 may be generated as being user-specific, i.e., usable only by a specific customer or user and for a specific purpose. The local license application package 118 may contain the license A in an encrypted form so that it is not seen or easily extracted by the customer / user. In some embodiments, the packaging tool 116 may create the local license application package 118 by hardcoding the license A into a binary executable of the local license application. In other embodiments, the packaging tool 116 may create the local license application package 118 by storing the license A in an encrypted archive file and hardcoding a key thereof into the binary executable of the local license application.202408066

[0024] The packaging tool 116 may be triggered by the first license server 104 to create a local license application package 118 when the customer / user purchases the license A via the first license server 104. In some embodiments, the packaging tool 116 may also be triggered by the first license server 104 to create a new local license application package 118 when the license A is renewed or refreshed.

[0025] Renewal refers to a scenario when the license A has expired before the expiration date of the license B that is wrapped therein. Customers of the vendor A may receive a license A that has a starting date / expiration date according to the beginning and end of their subscription period, which can be, for example, one year. At the end of that period, a customer may have to renew the license A, which can then be valid for another year. Therefore, in this example, the vendor A must generate a new license A for the customer that is valid for another year. The packaging tool 116 may be triggered by the first license server 104 to create a renewed local license application package 118 when the customer / user renews the license A via the first license server 104. The renewed local license application package 118 may contain, in an encrypted form, a new license A with an extended validity period, including wrapped therewithin an existing license B.

[0026] Refreshing refers to a scenario when a new license B is needed. For example, the vendor B might eventually bring out a new release for software B and software A needs to be migrated to this new release. It may also be that the current license B is going to expire, and the vendor A needs to receive a new one. Customers may then need to upgrade their applications using software A to the newest version. Once they upgraded to a new version which uses the new version of software B, they would also require a new license B. In this case, the packaging tool 116 may be triggered by the first license server 104 to automatically create a refreshed local license application package 118 at a predefined time before expiration of the license B, and make it available for download. The refreshed local license application package 118 may contain, in an encrypted form, the license A, including wrapped therewithin, a new license B with an extended validity period retrieved from the second license server 108.

[0027] The local license application package 1 18 may be deployed on one or more customer or user compute nodes 130 that has the software A installed thereon, via a distribution mechanism 120. A user compute node 130 may comprise, for example, an industrial edge device (TED).202408066

[0028] The embodiment shown in FIG. 1 depicts one possible, non-limiting configuration of a distribution mechanism 120 based on an industrial edge infrastructure provided by Siemens®. In the shown configuration, the distribution mechanisml20 is realized by an industrial edge hub (IE Hub) application 124 hosted on an industrial edge cloud 122 and an industrial edge manager (IEM) application 128 hosted on an IEM node 126. The IE Hub 124 may act as a central access point for downloading and configuring the IEM 128. From the IE Hub 124, it may be possible to download the IEM operating system to enable the IEM on-premises and all necessary software for running the IEM 128. Furthermore, the IE Hub 124 may provide a repository of available edge application for download. The IEM 128 may be hosted on an on-premises IEM node 126 and can enable management of connected industrial edge devices and edge apps that are installed on each industrial edge device, among other functions.

[0029] In the described distribution mechanism, the packaging tool 116 may make the local license application package 118, that it has created, available for download for the specific customer / user (e.g., including customer ID, software B version number, etc.) in the corresponding IE Hub 124. When a user compute node 130 is onboarded by attaching it to the IEM 128, the customer / user may choose to install the local license application package 118. The IEM 128 may then load the local license application package 118 from the IE Hub 124 and install it on the user compute node 130.

[0030] If an application that uses the software A is started on the user compute node 130, the licenses for both, the software A and the software B, must be provided. This can be accomplished by the local license application package 118. When installed on the user compute node 130, the local license application package 118 can decrypt the license A and create, on the user compute node 130, a localized version of the license A containing the license B by obfuscating or encrypting the license A with a local key generated using a unique node identifier associated with the user compute node 130. The localized version of the license A is thereby node-specific, and hence cannot be used outside the user compute node 130.

[0031] FIG. 2 illustrates a mechanism for validating the license B at the user compute node 130 according to one or more embodiments. According to the disclosed embodiments, the user compute node 130 may run software applications deployed thereon in self-contained containers (e.g., based on Docker). The containers may be managed by the software A on the user compute node 130. For this purpose, it may be ensured that the software A is sufficiently protected so that accessing it requires202408066 expensive hacking (e.g., no SSH login).

[0032] As shown, the containers may include a first container 202 for the local license application 204 and a second container 216 for a user application 218 that uses the software A. For example, if the software A is a framework software, the user application 218 may be an application developed using software A. If the software A is a platform software, the user application 218 may be an application that runs in the environment of software A. When the user application 218 is started, the first container 202 may communicate the localized version of the license A with the second container 216.

[0033] The local license application 204 may run, like other applications on the user compute node 130, in a container, which in this case is the container 202. As described above, the local license application (binary executable) 204 may contain, in an encrypted form, the license A, and therefore also the license B, ensuring that a user cannot read it even breaking into the container 202. The container 202 may also include a localizer tool 206. After installation of the local license application package, the localizer 206 may create a localized license A (i.e., a localized version of the license A) 212 directly on the user compute node 130. For this purpose, the localizer 206 may have the key to decrypt the license A, 112, which is encoded in the local license application 204, and therefrom extract the license B, 110. The localizer 206 may then create the localized license A, 212, by encrypting the license A, 112, with a local key generated using a node identifier 210 associated with the user compute node 130. In some embodiments, instead of an encryption, the localizer 206 may use an obfuscation mechanism (altering the license A, using the local key, in a way that makes it difficult to read or interpret) to generate the localized license A. The basic mechanisms of encryption and obfuscation are well known to one skilled in the art and will not be further described. The node identifier 210 may include any value (e g., device ID, address, etc.) that uniquely identifies the user compute node 130. For example, the node identifier 210 can be retrieved by the localizer 206 from a node ID lookup 208, such as an edge service running on the user compute node 130, among other options.

[0034] The localized license A, 212, contains therein the license B, 110. Being a localized license, it may only work in the compute node on which it is created. In some embodiments, the localized license A may be generated with a limited lifetime on the user compute node 130 and replaced with a defined frequency (e.g., every day).202408066

[0035] When the user application 218 is started, the localized license A, 212, may be communicated to the container 216 in which the user application 218 is running. To use the localized license A, 212, the container 216 may be provided with a license software development kit (SDK) 222. The license SDK 222 may be provided by the vendor A, via the software A managing the containers on the user compute node 130.

[0036] The localized license A, 212, may be communicated to the container 216 in multiple ways. In some embodiments, as illustrated in FIG. 2, after the local license application package is installed on the user compute node 130, the container 202 (via the localizer 206) may store the localized license A, 212, in a file system 214 of the user compute node 130. When the user application 218 is started, a folder containing the localized license A, 212, may be mounted into the container 216. Using the file system may be a convenient approach because it can be an easily accessible option of Docker to mount folders into containers. Furthermore, this approach may not require developing extra communication solutions, which also need to be maintained.

[0037] In other embodiments, the container 202 may be configured as a server including an API usable by the container 216 to request the localized license A, 212, using a network communication protocol. The communication protocol may include a TCP-based (e.g., HTTP) or other inter-process communication protocol. This approach may provide increased safety as it may be possible to exchange the localized license A via end-to-end encryption, e.g., using HTTP protocol. Furthermore, the approach may be suitably implemented in non-native environments, e.g., a Siemens® software running on an Amazon® environment. In an example implementation, the container 202 may offer a RESTful API, which can be used by the container 216 to request a license when the user application 218 is started. The RESTful API may have access restrictions, restricting access to the local compute node. To ensure chain of custody, the request authority could be limited to library functions of the license SDK 222. For that purpose, the license SDK 222 must have credentials that enable it to request access. To tackle the problem of how the user application 218 can find the URL for the RESTful service, a directory service may be provided, which may use IP multicast to inform subscribers to the information. It may also be possible to configure the container 202 so that it always has the same IP address.

[0038] As described, the user application 218 uses the software A, which, in turn, depends on the software B. When the user application 218 is started, it may use the software B. Accordingly, an API202408066220 of the software B would require the license B, which may be provided by the license SDK 222. The license SDK 222 may read the localized license A, 212, communicated by the container 202 using any of the approaches described above. The license SDK 222 may also look up the node identifier 210 of the user compute node 130, for example, from the edge service 208. The license SDK 222 may then use the node-identifier 210 to de-obfuscate or decrypt the localized license A, 212, to obtain the license A and therefrom extract the license B. Subsequently, the license SDK 222 may hand over the license B to the software B API 220, for example by calling a library function. After that, the chain is completed, and the licenses are made available.

[0039] In some embodiments, the license SDK 222 may extract the license B dependent on checking whether an expiration date of the license A is reached. If reached, the license SDK 222 may return a “null” or an invalid license to the software B API 220, which would block the user from further using the software B. In this case, the system may keep on functioning beyond the expiration date of the license A. However, subsequently, once the user application 218 shuts down and restarts, it will require a de-obfuscation or decryption of the localized license, which would fail. In other embodiments, the license SDK 222 may include a sleeping thread configured to be woken up or activated when an expiration date of the license A is reached, forcing the user application to be terminated. In this case, the user will be denied access to use the software B immediately after the expiration of the license A.

[0040] The embodiments of the present disclosure may be implemented with any combination of hardware and software. In addition, the embodiments of the present disclosure may be included in an article of manufacture (e.g., one or more computer program products) having, for example, a non- transitory computer-readable storage medium. The computer readable storage medium has embodied therein, for instance, computer readable program instructions for providing and facilitating the mechanisms of the embodiments of the present disclosure. The article of manufacture can be included as part of a computer system or sold separately.

[0041] The computer readable storage medium can include a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. Computer readable program instructions described herein can202408066 be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network.

[0042] The system and processes of the figures are not exclusive. Other systems, processes and menus may be derived in accordance with the principles of the disclosure to accomplish the same objectives. Although this disclosure has been described with reference to particular embodiments, it is to be understood that the embodiments and variations shown and described herein are for illustration purposes only. Modifications to the current design may be implemented by those skilled in the art, without departing from the scope of the appended claims.

Claims

202408066CLAIMSWhat is claimed is:

1. A computer-implemented method for managing third-party software licenses, comprising: generating a first license for a first software by a first license server, the first license including wrapped therein a second license for a second software retrieved from a second license server of a third-party vendor, wherein functionality of the first software depends on the second software, creating, via packaging tool, a downloadable user-specific local license application package that contains the first license in an encrypted form, and deploying the local license application package on a user compute node that has the first software installed thereon, wherein the local license application package, when installed on the user compute node, is configured to decrypt the first license and create, on the user compute node, a localized version of the first license containing the second license by obfuscating or encrypting the first license with a local key generated using a unique node identifier associated with the user compute node.

2. The method according to claim 1, wherein the second license retrieved from the second license server and the first license generated by the first license server are not limited to a specific user.

3. The method according to any of claims 1 and 2, wherein the packaging tool creates the local license application package by hardcoding the first license into a binary executable application.

4. The method according to any of claims 1 and 2, wherein the packaging tool creates a local license application package by storing the first license in an encrypted archive file and hardcoding a key thereof into a binary executable application.2024080665. The method according to any of the preceding claims, wherein the localized version of the first license is generated with a limited lifetime on the user compute node and replaced with a defined frequency.

6. The method according to any of the preceding claims, wherein the first software is a framework or platform software.

7. The method according to any of the preceding claims, wherein the user compute node is configured to run software applications deployed thereon in containers, the containers including a first container for the local license application package and a second container for a user application that makes use of the first software, and thereby, also the second software, wherein the first container is configured to communicate the localized version of the first license with the second container when the user application is started.

8. The metho according to claim 7, the first software is configured to manage the containers on the user compute node.

9. The method according to and of claims 7 and 8, wherein the first container is configured to store the localized version of the first license in a file system of the user compute node, and, when the user application is started, mount a folder containing the localized version of the first license into the second container.

10. The method according to any of claims 7 and 8, wherein the first container is configured as a server including an API usable by the second container to request the localized version of the first license using a network communication protocol.

11. The method according to any of claims 7 to 10, wherein the second container includes a license software development kit (SDK) configured to perform, when the user application is started: read the localized version of the first license communicated by the first container, look up the node identifier of the user compute node, and use the node-identifier to de-obfuscate or decrypt the localized version of the first license to obtain the first license and therefrom extract the second license.20240806612. The method according to claim 11, wherein the license SDK is configured to extract the second license dependent on checking whether an expiration date of the first license is reached.

13. The method according to claim 11, wherein the license SDK includes a sleeping thread configured to be activated when an expiration date of the first license is reached, forcing the user application to be terminated.

14. The method according to any of the preceding claims, wherein the packaging tool is triggered by the first license server to create a renewed local license application package when the user renews the first license via the first license server, the renewed local license application package containing, in an encrypted form, a new first license with an extended validity period, including wrapped therewithin an existing second license.

15. The method according to any of the preceding claims, wherein the packaging tool is triggered by the first license server to automatically create a refreshed local license application package at a predefined time before expiration of the second license, the refreshed local license application package containing, in an encrypted form, the first license, including wrapped therewithin, a new second license with an extended validity period retrieved from the second license server.

16. A non-transitory computer-readable storage medium including instructions that, when processed by one or more processors, configure the one or more processors to perform the method according to any one of claims 1 to 1 .

17. A system, comprising: one or more processors, and memory storing instructions executable by the one or more processors to perform a method according to any of claims 1 to 15.

Images