License Usage Manager (LUM) - Overview¶
Overview¶
License Usage Manager (LUM) is a standalone micro-service with its own database. LUM is intended for answering the question on whether the specific action on the software asset is entitled for specific user. From licensing point of view, the company that uses Acumos can either be the software licensor (supplier) that produces the software (model) or the licensee (subscriber) that consumes the software (model).
For LUM to answer the question on whether the user is entitled to perform an action on the software asset, it needs to have the following information
- the software identifying tag information
swidTag
. The key toswidTag
record isswTagId
that is the same as therevisionId
in Acumos- the indication on
swidTag
of whether the right-to-use is required for asset usageisRtuRequired
that is found in the license profile of the software- when
isRtuRequired==true
, LUM also needs to have the agreement provided from supplier to the subscriber that contains one or many right-to-use items (permission and/or prohibition) that target theswidTag
and limiting the user usage through constraint on assignee, limiting thetime
of usage through the enable-on constraint and/or the expire-on constraint, as well as limiting the usagecount
for each action on the asset usage identified byassetUsageId
Integration and interaction of LUM-server with Acumos and RTU-editor¶
The birds-view of the licensing process in Acumos¶
Description of the user licensing activities in Acumos and its busness supporting systems (BSS)¶
¶ step action supplier or subscriber user role or component activity description c1 onboard supplier creator model creator creates the model and globally identifies it with swidTag
. Optionally, the creator can also provide the license profilec2 onboard supplier creator model creator onboards the model and swidTag
into Acumos
¶ step action supplier or subscriber user role or component activity description p1 prepare supplier publisher model publisher uses the license-profile-editor to fill out the license profile and specify isRtuRequired
p2 and p3 publish or federate supplier publisher model publisher uploads the license profile into Acumos and initiates the publish or federate action on the model p4 publish or federate supplier LMCL inside Acumos-1 registers the software in LUM-server-1 by sending swidTag
andisRtuRequired
p5, p6, p7 publish or federate supplier Acumos-1 sends the model, swidTag
, and the license-profile withisRtuRequired
to Acumos-2 on supplier (licensee) side through the Acumos peer-to-peer tunnelp8 publish or federate subscriber Acumos-2 receives the model, swidTag
, and the license-profile withisRtuRequired
p9 publish or federate subscriber Acumos-2 registers the software in LUM-server-2 by sending swidTag
andisRtuRequired
¶ step action supplier or subscriber user role or component activity description u1 request subscriber user model user is trying to perform an action on the model in Acumos-2 u2 ask for entitlement subscriber LMCL inside Acumos-2 asks LUM-server-2 whether the asset-usage with action is entitled for the userId
onassetUsageId
with software identifierswTagId
(revisionId
in Acumos)u2 yes or no subscriber LUM-server-2 LUM-server-2 answers with yes or no u2 allow or error subscriber LMCL inside Acumos-2 if the asset usage is not entitled, an error with denial(s) is shown to the user. If the asset usage is entitled, LMCL allows Acumos-2 to perform the action.
¶ step action supplier or subscriber user role or component activity description s1 open RTU-editor in browser supplier sales rep open RTU-editor web page from RTU-Editor-web-server-1 s2 open RTU-editor in browser supplier sales rep open RTU-editor web page is served by RTU-Editor-web-server-1 s2 RTU-editor in browser supplier sales rep enter agreement with the right-to-use into the RTU-editor web page s3 download supplier sales rep download the agreement with the right-to-use into the RTU-agreement.json file s4 send supplier sales rep send the email with the attached RTU-agreement.json file to subscriber
¶ step action supplier or subscriber user role or component activity description r1 receive subscriber RTU rep receives the email with the attached RTU-agreement.json file from the supplier r2 open RTU-editor in browser subscriber RTU rep open RTU-editor web page from RTU-Editor-web-server-2 r3 open RTU-editor in browser subscriber RTU rep open RTU-editor web page is served by RTU-Editor-web-server-2 r4 import subscriber RTU rep import the RTU-agreement.json into the RTU-editor web page r4 verify subscriber RTU rep verify the agreement with the right-to-use in the RTU-editor web page r5 save subscriber RTU rep save the agreement with the right-to-use into LUM-server-2
¶ step action supplier or subscriber user role or component activity description r1 receive subscriber RTU rep receives the email with the attached RTU-agreement.json file from the supplier a1 hand it to admin subscriber RTU rep + LUM admin RTU rep hands the RTU-agreement.json file to LUM admin a2 http PUT through swagger-ui subscriber LUM admin LUM admin uploads the content of the RTU-agreement.json file into LUM-server-2 through swagger-ui on LUM-server-2. See LUM - Application Programming Interface (API)
LUM assumptions and functions¶
LUM expects the software-management-system (Acumos) to globally identify the software up to its unique version and provide the software-identifying tag data (swidTag) along with the license-profile to LUM. License-Manager-Client-Library (LMCL) in Acumos is responsible for determining whether the swidTag requires the right-to-use or not. Open source software usually does not require the right-to-use from the licensor.
LUM expects the software-management-system (License-management-client in Acumos) to identify the software asset usage. In other words, it is Acumos’s responsibility to differentiate between separate copies of the software and come up with globally unique identifier for the asset-usage of that specific copy of the software.
Open Digital Rights Language (ODRL) is used for defining the agreement/entitlement with multiple permission rules - rights-to-use that contain multiple constraint/limits.
Note
- LUM only implements a subset of ODRL features that include agreement, permission, and prohibition.
- LUM does not support logical constraint and some other features of ODRL. Please refer to LUM API for more details.
- However, LUM has its own set of additional values with the prefix
lum:
and a special operatorlum:in
to find the match in a list ofrightOperand
values.
The ODRL based agreement between the software licensor (supplier) and software licensee (subscriber) that contains one or more permission and/or prohibition is expected to be uploaded to LUM through admin API.
On request for entitlement of the asset-usage, LUM goes through the following sequence
- finds swidTag with the license-profile in LUM database
- identifies whether the swidTag requires the right-to-use or not
- if the right-to-use is required, LUM finds the matching right-to-use (prohibition or permission) for the software and determines whether the asset-usage is entitled or not based on the constraint